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Ad hoc On-Demand Distance Vector (AODV) Routing 

Status of this Memo 

This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 

Copyright Notice 

Copyright (C) The Internet Society (2003) . All Rights Reserved. 
Abstract 

The Ad hoc On-Demand Distance Vector (AODV) routing protocol is 
intended for use by mobile nodes in an ad hoc network. It offers 
quick adaptation to dynamic link conditions, low processing and 
memory overhead, low network utilization, and determines unicast 
routes to destinations within the ad hoc network. It uses 
destination sequence numbers to ensure loop freedom at all times 
(even in the face of anomalous delivery of routing control messages) , 
avoiding problems (such as "counting to infinity") associated with 
classical distance vector protocols. 
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1. Introduction 

The Ad hoc On-Demand Distance Vector (AODV) algorithm enables 
dynamic, self -starting, multihop routing between participating mobile 
nodes wishing to establish and maintain an ad hoc network. AODV 
allows mobile nodes to obtain routes quickly for new destinations, 
and does not require nodes to maintain routes to destinations that 
are not in active communication. AODV allows mobile nodes to respond 
to link breakages and changes in network topology in a timely manner. 
The operation of AODV is loop-free, and by avoiding the Bellman-Ford 
"counting to infinity" problem offers quick convergence when the ad 
hoc network topology changes (typically, when a node moves in the 
network) . When links break, AODV causes the affected set of nodes to 
be notified so that they are able to invalidate the routes using the 
lost link. 
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One distinguishing feature of AODV is its use of a destination 
sequence number for each route entry. The destination sequence 
number is created by the destination to be included along with any 
route information it sends to requesting nodes. Using destination 
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sequence numbers ensures loop freedom and is simple to program. 
Given the choice between two routes to a destination, a requesting 
node is required to select the one with the greatest sequence number. 

2 . Overview 

Route Requests (RREQs) , Route Replies (RREPs) , and Route Errors 
(RERRs) are the message types defined by AODV. These message types 
are received via UDP, and normal IP header processing applies. So, 
for instance, the requesting node is expected to use its IP address 
as the Originator IP address for the messages. For broadcast 
messages, the IP limited broadcast address (255.255.255.255) is used. 
This means that such messages are not blindly forwarded. However, 
AODV operation does require certain messages (e.g., RREQ) to be 
disseminated widely, perhaps throughout the ad hoc network. The 
range of dissemination of such RREQs is indicated by the TTL in the 
IP header. Fragmentation is typically not required. 

As long as the endpoints of a communication connection have valid 
routes to each other, AODV does not play any role. When a route to a 
new destination is needed, the node broadcasts a RREQ to find a route 
to the destination. A route can be determined when the RREQ reaches 
either the destination itself, or an intermediate node with a 'fresh 
enough 1 route to the destination. A 'fresh enough' route is a valid 
route entry for the destination whose associated sequence number is 
at least as great as that contained in the RREQ. The route is made 
available by unicasting a RREP back to the origination of the RREQ. 
Each node receiving the request caches a route back to the originator 
of the request, so that the RREP can be unicast from the destination 
along a path to that originator, or likewise from any intermediate 
node that is able to satisfy the request. 

Nodes monitor the link status of next hops in active routes. When a 
link break in an active route is detected, a RERR message is used to 
notify other nodes that the loss of that link has occurred. The RERR 
message indicates those destinations (possibly subnets) which are no 
longer reachable by way of the broken link. In order to enable this 
reporting mechanism, each node keeps a "precursor list", containing 
the IP address for each its neighbors that are likely to use it as a 
next hop towards each destination. The information in the precursor 
lists is most easily acquired during the processing for generation of 
a RREP message, which by definition has to be sent to a node in a 
precursor list (see section 6.6) . If the RREP has a nonzero prefix 
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length, then the originator of the RREQ which solicited the RREP 
information is included among the precursors for the subnet route 
(not specifically for the particular destination) . 

A RREQ may also be received for a multicast IP address. In this 
document, full processing for such messages is not specified. For 
example, the originator of such a RREQ for a multicast IP address may 
have to follow special rules. However, it is important to enable 
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correct multicast operation by intermediate nodes that are not 
enabled as originating or destination nodes for IP multicast 
addresses, and likewise are not equipped for any special multicast 
protocol processing. For such multicast -unaware nodes, processing 
for a multicast IP address as a destination IP address MUST be 
carried out in the same way as for any other destination IP address. 

AODV is a routing protocol, and it deals with route table management. 
Route table information must be kept even for short-lived routes, 
such as are created to temporarily store reverse paths towards nodes 
originating RREQs. AODV uses the following fields with each route 
table entry: 

Destination IP Address 

Destination Sequence Number 

Valid Destination Sequence Number flag 

Other state and routing flags (e.g., valid, invalid, repairable, 
being repaired) 
Network Interface 
- Hop Count (number of hops needed to reach destination) 
Next Hop 

List of Precursors (described in Section 6.2) 
Lifetime (expiration or deletion time of the route) 

Managing the sequence number is crucial to avoiding routing loops, 
even when links break and a node is no longer reachable to supply its 
own information about its sequence number. A destination becomes 
unreachable when a link breaks or is deactivated. When these 
conditions occur, the route is invalidated by operations involving 
the sequence number and marking the route table entry state as 
invalid. See section 6.1 for details. 

3 . AODV Terminology 

This protocol specification uses conventional meanings [1] for 
capitalized words such as MUST, SHOULD, etc., to indicate requirement 
levels for various protocol features. This section defines other 
terminology used with AODV that is not already defined in [3] . 
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active route 

A route towards a destination that has a routing table entry 
that is marked as valid. Only active routes can be used to 
forward data packets . 

broadcast 

Broadcasting means transmitting to the IP Limited Broadcast 
address, 255.255.255.255. A broadcast packet may not be 
blindly forwarded, but broadcasting is useful to enable 
dissemination of AODV messages throughout the ad hoc network. 
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destination 

An IP address to which data packets are to be transmitted. 
Same as "destination node". A node knows it is the destination 
node for a typical data packet when its address appears in the 
appropriate field of the IP header. Routes for destination 
nodes are supplied by action of the AODV protocol, which 
carries the IP address of the desired destination node in route 
discovery messages. 

forwarding node 

A node that agrees to forward packets destined for another 
node, by retransmitting them to a next hop that is closer to 
the unicast destination along a path that has been set up using 
routing control messages. 

forward route 

A route set up to send data packets from a node originating a 
Route Discovery operation towards its desired destination. 

invalid route 

A route that has expired, denoted by a state of invalid in the 
routing table entry. An invalid route is used to store 
previously valid route information for an extended period of 
time. An invalid route cannot be used to forward data packets, 
but it can provide information useful for route repairs, and 
also for future RREQ messages. 
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originating node 

A node that initiates an AODV route discovery message to be 
processed and possibly retransmitted by other nodes in the ad 
hoc network. For instance, the node initiating a Route 
Discovery process and broadcasting the RREQ message is called 
the originating node of the RREQ message. 

reverse route 

A route set up to forward a reply (RREP) packet back to the 
originator from the destination or from an intermediate node 
having a route to the destination. 

sequence number 
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A monotonically increasing number maintained by each 
originating node. In AODV routing protocol messages, it is 
used by other nodes to determine the freshness of the 
information contained from the originating node. 

valid route 

See active route. 

4. Applicability Statement 

The AODV routing protocol is designed for mobile ad hoc networks with 
populations of tens to thousands of mobile nodes. AODV can handle 
low, moderate, and relatively high mobility rates, as well as a 
variety of data traffic levels. AODV is designed for use in networks 
where the nodes can all trust each other, either by use of 
preconf igured keys, or because it is known that there are no 
malicious intruder nodes. AODV has been designed to reduce the 
dissemination of control traffic and eliminate overhead on data 
traffic, in order to improve scalability and performance. 
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5. Message Formats 

5.1. Route Request (RREQ) Message Format 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type |J|R|G|D|U| Reserved | Hop Count | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RREQ ID | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Destination IP Address | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Destination Sequence Number | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Originator IP Address | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Originator Sequence Number | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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The format of the Route Request message is illustrated above, and 
contains the following fields: 

Type 1 

J Join flag; reserved for multicast. 

R Repair flag; reserved for multicast. 

G Gratuitous RREP flag; indicates whether a 

gratuitous RREP should be unicast to the node 
specified in the Destination IP Address field (see 
sections 6.3, 6.6.3). 

D Destination only flag; indicates only the 

destination may respond to this RREQ (see 
section 6.5). 

U Unknown sequence number; indicates the destination 

sequence number is unknown (see section 6.3). 

Reserved Sent as 0; ignored on reception. 

Hop Count The number of hops from the Originator IP Address 

to the node handling the request. 
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RREQ ID A sequence number uniquely identifying the 

particular RREQ when taken in conjunction with the 
originating node's IP address. 

Destination IP Address 

The IP address of the destination for which a route 
is desired. 

Destination Sequence Number 

The latest sequence number received in the past 
by the originator for any route towards the 
destination. 

Originator IP Address 

The IP address of the node which originated the 
Route Request. 

Originator Sequence Number 

The current sequence number to be used in the route 
entry pointing towards the originator of the route 
request . 

5.2. Route Reply (RREP) Message Format 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type l R l A l Reserved | Prefix Sz| Hop Count | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
[ Destination IP address | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Destination Sequence Number | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Originator IP address | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-*+-+-+ 
j Lifetime | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

The format of the Route Reply message is illustrated above, and 
contains the following fields: 



Type 2 

R Repair flag; used for multicast. 

A Acknowledgment required; see sections 5.4 and 6.7. 

Reserved Sent as 0; ignored on reception. 
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Prefix Size If nonzero, the 5 -bit Prefix Size specifies that the 
indicated next hop may be used for any nodes with 
the same routing prefix (as defined by the Prefix 
Size) as the requested destination. 

Hop Count The number of hops from the Originator IP Address 

to the Destination IP Address. For multicast route 
requests this indicates the number of hops to the 
multicast tree member sending the RREP. 

Destination IP Address 

The IP address of the destination for which a route 
is supplied. 

Destination Sequence Number 

The destination sequence number associated to the 
route . 

Originator IP Address 

The IP address of the node which originated the RREQ 
for which the route is supplied. 

Lifetime The time in milliseconds for which nodes receiving 

the RREP consider the route to be valid. 

Note that the Prefix Size allows a subnet router to supply a route 
for every host in the subnet defined by the routing prefix, which is 
determined by the IP address of the subnet router and the Prefix 
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Size. In order to make use of this feature, the subnet router has to 
guarantee reachability to all the hosts sharing the indicated subnet 
prefix. See section 7 for details. When the prefix size is nonzero, 
any routing information (and precursor data) MUST be kept with 
respect to the subnet route, not the individual destination IP 
address on that subnet. 

The 'A* bit is used when the link over which the RREP message is sent 
may be unreliable or unidirectional. When the RREP message contains 
the ' A ' bit set, the receiver of the RREP is expected to return a 
RREP-ACK message. See section 6.8. 
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5.3. Route Error (RERR) Message Format 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type |N| Reserved | DestCount | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Unreachable Destination IP Address (1) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Unreachable Destination Sequence Number (1) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- j 
| Additional Unreachable Destination IP Addresses (if needed) j 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Additional Unreachable Destination Sequence Numbers (if needed) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

The format of the Route Error message is illustrated above, and 
contains the following fields: 



Type 
N 



No delete flag; set when a node has performed a local 
repair of a link, and upstream nodes should not delete 
the route . 



Reserved Sent as 0; ignored on reception. 

DestCount The number of unreachable destinations included in the 
message; MUST be at least 1. 



Unreachable Destination IP Address 

The IP address of the destination that has become 
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unreachable due to a link break. 

Unreachable Destination Sequence Number 

The sequence number in the route table entry for 
the destination listed in the previous Unreachable 
Destination IP Address field. 

The RERR message is sent whenever a link break causes one or more 
destinations to become unreachable from some of the node's neighbors. 
See section 6.2 for information about how to maintain the appropriate 
records for this determination, and section 6.11 for specification 
about how to create the list of destinations. 
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5.4. Route Reply Acknowledgment (RREP-ACK) Message Format 

The Route Reply Acknowledgment (RREP-ACK) message MUST be sent in 
response to a RREP message with the 'A' bit set (see section 5.2). 
This is typically done when there is danger of unidirectional links 
preventing the completion of a Route Discovery cycle (see section 
6.8) . 

0 1 

0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Reserved | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 4 

Reserved Sent as 0/ ignored on reception. 
6. AODV Operation 

This section describes the scenarios under which nodes generate Route 
Request (RREQ) , Route Reply (RREP) and Route Error (RERR) messages 
for unicast communication towards a destination, and how the message 
data are handled. In order to process the messages correctly, 
certain state information has to be maintained in the route table 
entries for the destinations of interest. 

All AODV messages are sent to port 654 using UDP. 

6.1. Maintaining Sequence Numbers 

Every route table entry at every node MUST include the latest 
information available about the sequence number for the IP address of 
the destination node for which the route table entry is maintained. 
This sequence number is called the "destination sequence number". It 
is updated whenever a node receives new (i.e., not stale) information 



http://www.ietf.org/rfc/rfc3561 .txt 



05/13/2011 



